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Abstract 

This work explores (senu-)ausomated EC on the WWW. 
We outline a system in which trading panics present in* 
ts mi oris, .made of more efementary components, which are 
used u> express their willingness to engage in deals sub- 
ject to constraints. Parts of intentions may be variable 
components. Some variable components may be associated 
with computations that transform them into, usually, "more 
specified" components. This mechanism encodes business 
rules. By "fitting" intentions contracts are formed. 

The ECoaractsframeworkis a specific realization of the 
architecture, enables EC WWW sites and EC automated 
tools to present standardized information* This informa- 
tion (J) allows each party to decide whether it wishes to 
engage in an EC activity with the other party, (2) enables 
automated negotiation between the parties, and (3) enables 
the establishment of an electronic contract, i.e., a formal 
description of an agreed upon BC transaction. 

The ^Contracts framework defines the basic software 
components of an BC party and their interconnections. 
Based on the EContmcts framework, various applications 
can be built Examples are deal mdkhig applications, deal 
feasibility checkers, brokers etc. Furthermore, the defini- 
tions of the data structures and the algorithms enable a the* 
oretical investigation of automated commerce. 



1. Structuring Electronic Commerce 

Electronic Commerce (BO is expected to be the main 
activity on the WWW. Currently, EC is mainly hrowser- 
basad. This si cms primarily ftctu reliance On "local" 
technology, lack of standards and non-uniform interfaces. 
Browser-based interaction wastes a lot of customers 4 time. 
In the near future, we expect a rich network-based market- 
place, with hundreds it not thousands of major "players" 
find millions of smaller-scale "players, 1 ' Furthermore, we 
expect almost everything to be tradable online, from con* 



sumer goods to insurance policies, from real estate parcels 
to software. In this Jdnd of environment, browsing is a hope- 
less proposition* What is needed is a universal formalism 
("the HTML of EC") thai will support deal making on a 
global scale and protocols ("the HTTP of EC") that will 
enable the realization of automatic tools (agents). In this 
paper we outline a design to enable semi-automated EC on 
the WWW. By "semi-automatic," we leave open the possi- 
bility that a human decision maker takes part in the negoti- 
ation/decision phases of a commercial activity. 

Our vision is that parties (a general term designating in- 
dividuals, corporations, government entices, and other en- 
tities of legal standing) can specify intentions, a formal out- 
line of deals in which such parties are ready to engage. 
Intentions are made of components. Components may be 
atomic or compound (to any depth). Furthermore, a com- 
ponent may be a variable component, that is unspecified 
(except perhaps for type information). Furthermore, com- 
ponents may be inter-related (e.g., by containment, by edge 
ot labeled-edge connection, or by arbitrary predicates). An 
important facet of a variable component is its association 
with one or more computational devices (a generic term 
far hardware - including electronic and biological, software 
- programs, executable*, byre-codes, systems, servers and 
the like). Such a computational device, based on its per- 
ceived state (which may comprise inputs, values of various 
components, values of certain other entities such as files, 
databases) and messages, transforms a variable component 
into a component. The "new" component is usually "more 
specific" than the variable il replaces. The idea is that such 
variable components and their associated computational de- 
vices embody "transient," "policy dependent" or "current 
availability" aspect* of the willingness to engage* in a deal. 
]t Is desirable, although not mandatory, that the function* 
aliry of the computational device be readily understood by 
Inspection, a property we call anatyzability. 

Making a deal means reconciling the constraint* placed 
on deals by the (two or more) panic* involved. Pot ammUc- 
fry, let us concentrate on two parties, the notions general- 




ize lo muhi> party scenarios. By •'reconciling* we mean u as 
btit as possible subjeci lo the parties' directives as well as 
more general laws lh« may apply*'. Looking at two inten- 
tions, we can think of reconciling the constraints as a form 
of -fitting" muter constraints. Abstractly, this process "fits" 
the component structure of one party with the ^counterpart" 
components of the other party. We envision a party as em- 
ploying a computational entity, which we term "party ma- 
chine (PMX" which controls the fitting of inten tions, the PM 
may communicate wnb other computational devices, and in 
particular other PMs, in attaining its mission. For example, 
it may be responsible for activating the "fitting process** or 
activating the computational device associated with a vari- 
able component. 

There are some very basic requirements for supporting 
a scenario as outlined Above. Pirn, a common terminology 
for intentions is needed. The analogy here is the natural 
language used by humans, suitably formalized, for commer- 
cial activities. This means thai the intentions of a party be 
readily "understood" by other parries. Second, an agreed 
m upon archicectore is needed so that a PM of a party can as- 

sumo certain abilities of an PM of another party. An analogy 
~ here is the client-server architecture of the WWW. Third, as 

\Z stated, comptrtatloaai devices may issue messages and re- 

tl luire response, this forms a foundation for automated, or 

f~: semi-autornated, negotiations. So, as we deal with auto- 

mated tools, a protocol for negotiations need be established. 
*C Humans exercise such "protocols** all the time, although 

U1 they are mostly unaware of this fact (a_g., recall your last 

s visit to a rast food stand). 

O In designing solutions for the above mentioned three re- 

ro quirernents we list some desirable properties. The common 

yj terrjainology should be simple, yet expressive and powerful. 
L. The architecture should be modular and "orthogonal ie^ 
mfrerent modules should address different concerns. To ea- 
~ able a rich set of commerce modes, the structure and content 

— of EC parties should be rrtaehina-anaJyzable, Machine an- 

alyzabflity will give rise to greater efficiency as well (see 
below). Of course, an EC party should be able to faavs 
"opaqucr portions that era not viewable by other parties, 

Using these concepts, various applications can be buflt. 
Examples are deal making applications, brokers, deal feasi- 
bility checkers, etc. Furthermore, the definitions of the data 
structures and aJ gentium enable a formal investigation of 
automated commarca. 

The HCoatract framework presented in this paper is a 
step towards achieving the goals just outlined. It is a realiza- 
tion of the concepts outlined above. We should note, how- 
ever, thai other realizations of these concepts are possible. 
In the interest of concertinas, we have chosen for ECoatract 
a "logical flavor 0 along the lines of Prolog 'and logic pro- 
gramming. Other realizations may rely on IXSP and func- 
tional prograrruning, on more natural language oriented for- 




malisms, on Java, C++ and Object Oriented formalisms and 
rnany more. By being concrete, we explore the promise of 
our approach and are able to formulate technical problems 
whose computational complexity may be evaluated. 

The first step is to ensure that intentions axe universally 
understood For this we need a mechanism for forming in- 
tentions, In BConrracts, a component is represented as a 
Tooied labeled ire*. Jn fact, an intention is also a rooted la- 
beled tree which is composed of components, together with 
various constraints. The most basic components are sim- 
ple aiotaic tniilits, o.g., of type integer, float, string. Next 
are basic components that are essentially (usually small) 
trees whose structure is agreed upon to represent a concept 
(e.g. car, buy, address). These basic components are called 
classes and they form the "words" of the common language. 
The word "class" hints at the fact that in an object oriented 
realization, these component are likely to be represented as 
(object oriented) classes. A component may be a variable 
component. In this case it appears as a single node labeled 
with a typed variable (its atomic type or its class name). 

Using classes, the parties compose their intentions, es- 
sentially framing "sentences ,, which in utrn define possible 
deals. As noted, the purpose of an intention is to describe 
a deal that a party is willing to engage in. For example, an 
intention can express that the BcoksOnline. Carp, is idling 
bocks and that (fyou buy more than jhv books, you receive 
a 3Cr% discount In BConrracts, the mechanism that com- 
poses wonts into sentences (classes into intentions) relies 
on '^variable instantiation" and the introduction of "operator 
nodes." A (leaf) variable component of an intention may be 
associated with a computation device, called a ''commerce 
automaton" (CA) in this realization, which prescribes how 
the variable may be instantiated further during a later phase, 
A commerce automaton may outline a message exchange 
sequence between the parties. In addition to intentions, 
an EC party also maintains parry information, a relational 
database containing information relevant to the party's ac- 
tivities. This is part of the "system state'*. 

A deal is manifested by creating a mum ally agreed upon 
tlMfOnlc contract (&Centract). The proa**! of obtaining 
an BContraet begin* with two imtinl intentions, presented 
by the parties. A formal process, called unification, a pan 
of me realization of "fining", is used to construct an agreed 
upon EContract. provided such a contract is feasible. Uni- 
fication may also be used by an EC party to deteorrninB 
whether an EContract Is at all possible, prior to entering ac- 
tual negotiations with the other party. Hence the importance 
of machine anaiyzability. 

The EContract framework defines the basic software 
components of an EC parry and their interconnections. The 
smicture of no EC party ia shown la Figure I, the £Con- 
tracts realization of a PM ia; 

• The Negotiation Control Program (NOP) is an overall co- 



m 
a 

in 

M 

c 
n 
w 

u 



• lafQAcioas 

frarly machine (FM) 



Control Program 



I 



tinted/ | | CoAstraijit SoN6c 1 



Auttm&U 
Exccedon 



Figure 1. Party architecture 

ordinate*. 

The Consucaiati Solver is used to check sas 0/ con- 



♦ The Automata Execution Engine (A££> execmes com- 
merce automata. 

♦ The Unifier supervises the unificatSop process. 

The paper is organized as follows. Section 2 presents 
the basic terminology of EContracts. Section 3 defines in- 
tentions. Id particular, it presents the commerce automata 
formalism and the way parties exchange messages during 
negotiations. Section 4 discusses; unification, as well as up- 
graded unification" that allows to perform unification by 
"relaxing" certain constraints. The ECon tracts unification 
algorithm is presented in an Appendix. The EC party sys- 
tem architecture is briefly discussed in Section 5. Section 6 
presents related work. Conclusions are presented in Section 
7. 

2. Basics of the EContracts framework 

The parties involved in an EC activity must agree on a 
common vocabulary. The "Svords" of this vocabulary are 
called classes and, formally, they are rooted labeled ordered 
(RLO) trees. The root of a class is labeled with the class 
name\ the edges of the class are labeled with strings whicb 
hint at the function of the vftrticaa; the leave* of the classes 
are labeled with typed variables. 

Examples of classes are presented in Figure 2. We omit 
the type or the name of the variables when It is either ir- 
relevant ox clear from the context. For example, the Put- . 
Phase contract class (Figure 2(a)) describes a used vehicle 
purchase transaction involving a customer, a used vehicle 
dealer, a list of purchased vehicles and a payment 

The presence of variables in a class enables its cus- 
tomisation. The** am four types of yariables: 

• Atomic variable* The names of atomic variables begin 
with a $ and the values that can be assigned to these vari- 
ables are atomio values. Le., string, real and integer, 

• Class variables The names of class variables begin with 
a & and the values that can be assigned to these variables 



are class instances. 
• ♦ Atomic list variables The names of atomic list variables 

begin with a % and the values that can be assigned to these 

variables are lists of atomic values. 
• Class list variables The names of class list variables are 

enclosed between parentheses and the values that can be 

assigned to these variables are lists of class instances. 
These notions are captured in the following definitions. 
We define the atomic types to be string, integer and real. 
Other types like date, boolean ox enumerated types are pos- 
sible. We limit ourselves to string, integer and real for the 
sake 0/ simplicity. We assume the existence of a set of class 
names which is a set of strings. 

Definition 2.1 A value is either a siring, an miegen a real, 

a class name or one of the special symbols 13 (for null). IL 

(for lists) or ^ for consriuinis. □ 

definition 12 A variable is a triple (i t n,v) where t is an 

atomic type or a class nam*, n is a string and v is a value. 

□ 

n is the name of the variable. A triple (t, n, a) must satisfy 
the naming constraints dtfin&d above (e.g., atomic variable 
names must begin with a $ character), together with the ob- 
vious type-correctness constraint between i, n said v (i.e>, a 
value must correspond to the type of the variable). A vari- 
able (t , », v) is unbound if * = H. A set of variables V is 
proper if every variable name in a triple of V is unique. Le., 
appears in no other triple as the name component. 

We define the words of the common vocabulary, namely 
the classes. 

Definition 23 A class, over a proper set of unbound vari' 
abUs VA& is a rooted labeled ordered (RLO) tree, denoted 
( V. B t r, U <c> eif, vlj), Where 

# V is a set cf vertices. 

• E is a set of edges* i? C V x V, 

♦ r € V is the root of the tree, 

♦ t. the label of the root, is a class name, 

* <„ is a partial order relation over B that defines the 
relative order of the edges that emanate from the same 
vertex, 

♦ elf i & STXJNOS is the edge labeling function 
(defined so that the labels of the edges that euuxnate from 
the same vertex are ail distinct), and 

• LetV g V be the haves of T. vtf ; V VAsX is the 
(total and onto) leaf lffot\m$ function* O 

In Figure % we represent the variable (i, n, N) by u n, 

Closes are organized in class hierarchies, each defining 
a sped alization hierarchy. 

Definition 2.4 Let I be a finite set cf class names. A class 
hierarchy B over L is a directed labeled rooted tree in 
which every vertex Is labeled with a class name in No 
class name may appear twice In the trv*. Q 
For example. Car is a specialization of Vehicle. As a conse- 
o,uence, Car instances can appear in the list of vehicles of a 
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Figure 2. Examples of classes 



Purchase contract Soch a relationship between classes does 
not imply any structural similarity between them. 

An oniotogy is a set of hierarchies containing classes that 
are semaniicalry related. 

Definition IS Let L t Ln he poirwise disjoint sets of 

class names* An ontology over L t , L n is a set of class 
hierarchies Hi, . - -,H n over L u . . . ,X«. respectively 1 . □ 
A class named a facontained'ln an ontology O if a is a 
vertex label in a class hierarchy in O- A class named h is 
a child of a class named a in O if (1) mere exists a class ... 
hierarchy T in O such that T contains rwo vertices w and v 
labeled with a and b % respectively, and (2) there is an edge- 
from uiov. Lei the descendant relation be the reflexive and 
transitive closure of the child relation. 

We assume the existence of three ba$ic*OBtc>*o&a&> The 
contracts ontology contains the possible EG contracts (e^ . 
Purchase, Rent), The t/ems ontology contains goods and 
services (e.g., car; hair-cut) thattcan ibe the subjects of an 
EC activity. The general ontology contains EC general-con-- 
cepu (o.g., EC authority, payment, interest rate).- 

For each class name I defined in the basic ontologies we 
assume the existence of a canonical class tori* denoted &> 
te.» a class whose root is labeled with t. An Instance of type 
i is a class that Is isomorphic io C u \*~, identical op to a 
consistent renaming of variables. 

A pony is an active component that may be involved in 
an EC activity, for example an EC WWW site or a customer 
buying agent* The EContrfiCts framework assumes a sym- 
metric model, that is the structure of all parties involved in 
an EC activity is Identical. A party manages the party m- 
fomtation* Lo., a standard relational database that contains 
the party's global data, e.g., the parry's identify, item lists, 



the party's global i 

pha&a ever h\ « . . • , Ln . 



we will omit the 



pricing information etc. 

3. Intentions 

In addition to the party information, in order to be ma- 
chine analyzable, a party should include a formal specifica- 
tion of the way it operates, he., the skeleton of contracts it 
may-enter*** well as me business rules«and the constraints 
it enforces. The EContracts framework represents this in- 
formation in intentions- Whereas classes arc the "words'* 
in our common language, intensions are the "sentences" of 
this language. Sentences are built by connecting words- An 
intention is composed of an intention tree which is derived 
from c*as^ commerce automata which encode business 
rales,>and'a>/uwirtij.«Ju 

3,1. IntentioiOrees** 

Intention- trees describe (be structure of EContracts a 
party is willing to establish. Intention trees are derived 
from EC contract dasses-andiare^transformed into actual 
contracts by meiantUain^ Variables, in order to define the 
parry's requirements, and by adding operator vertices that 
enable the specification of powerful logical constraints. 

Fox example. In Figure 3 3 . the customer. J. Smith, wishes 
to purchase two motorcycles or, alternatively, an Economy 
class car He is ready to pay by either cash or checlSU In 
Figure 9, the PurchaseOnlrne Corp. is selling cars (one at a 

time) and U only accepting cash. 

Mote that the two, intention trees in Figures 8 and 9 are 

complementary. The purpose of unification is to detect this 

fact and to build a * 4 unined° tree from the intentions, namely 

theEContracv. 

a Since we teiet several dmc^io 
groupein^ag^ts uW^Sa^of ta7 




Variable instantiation. Formally, variables are instan- 
tiated by using the or operator. The a operator takes a tree 
and a variable-instantiation operation, and produces a tree 
as follows. Let J be an intention tree and let * « (t,n t K) 
be an unbound variable appealing in T. 

* If x is aa atomic, variable, and v is a value of type t, 
a(T t x = v) ~ T where V is presented in Figure 3(a)! 
1a the figure, (7) symbols represent (sub-)trees and {7} 
symbols represent vertices. 

• If x is a class variable, let f be a class name which is a 
descendant of t in an ontology and let be an instance 
of type*', a(T,x = 0£) A T where T^is presented in 
Figure 3(b). 

• If * is a class list variably let (*J *' B ) be a sequence 

of class names which are descendants of i in an ontology 
and let (0£, be instances of types ft,-..,*')* 
respectively, e* (OJ,. ^ r, where ^ 

ts is presented In Figure 3(c). Instantiadon of atomic list 
variables is defined similarly, 

♦ If^isaclasslinvariablejet^^ 

of class names which are descendants of i in an ontology 
and let (OJ , . . ., & n ) be instances of types (t{, . . .,t'Y 
respectively, a (r, * ^ {0[ , . . . , O^)) ^ IT. where T is 
presented in Figure 3(d). The meaning is that the list that 
oan be assigned to x must contain at least (OJ , . . . , C£). 
We say mat a must satisfy a list cotaammm constraint. 
This operation is a partial assignment, as it constrains 
the possible values of x. list containment constraints on 
atomic list variables are defined similarly. A list contain- 
ment constraint of the form * C (OJ, ...,<%) can be 
specified using OR vertices which are defined below. 
Operator vertices. Operator vertices are vertices la* 
belcd with the strings "AND." "OR" and "HOT?* Operator 
vertices are added to an intention tree by using the A oper- 
ator. Let The an intention tree, T* is derived by adding to 
T an operator vertex o as follows: 

• <> is an O& vertex or an AND vertex. Let a be ft vertex in 

let («, v) be an edge labeled with lab, and let V be the 
subtree rooted In v. Let V t , V 7 be trees isomorphic to V 
up to renaming of variables. A(T, u, o, (Vi, Vi)) = T 
where T is obtained from O by (1) removing V from 
O, (2) adding an edge (w, e) labeled /ce, and (3) adding 
edges ftome to the roow of Viand v*j (see Figure 4(a)). 

♦ 0 is a WOT vertex. Let vi and T4 be the two subtrees 
rooted at an AND vertex, such that their roots are not 
already NOT vertices, o can be added to the intention tree 
as the root of one of Vl. V% % as described in Figure 4(b) 

. (forVa), 

Figure 3 presents an example of the use of operator vertices. 
Recall that CO is a list containment constraint, e.g^ variable 
(x) , when instantiated, should contain at least 0\ and O*. 
The meaning is that the list of items (of type t) must contain 
at least O x and O q . or 0 4 and O s , but must not contain 




Figure 5. Using operator vertices 



In an intention, we require that the (sub-)trees rooted at 
vertices that are labeled with the same variable name be 
identical. 

3*2, Constraints 

An intention contains a set of constraints. A con* 
straxni is a function from a value assignment. (to a set of 
variables) to the boolean values TRUE and FALSE. The 
sub-language used for the expression of constraints is not 
part of the EContmcxs framework specifications For the 
sake of simplicity, in examples, we use a simple constraints 
snb-language called SIMPL£*C which is presented through 
examples. For example, not (Ground <$title)) AND 
<$price > 100 ) AND Uname a "John") 
AND <{$na»e, $pr±ce) € a) is a constraint. 
Note that Ground means Is not nuir and £ denotes a 
set (relation) of tuples. The assignment C —{tfrtitle 
^ Sprice 1— 150, $name "John", a ~ 

{(^JohnMJOXC^teve^nO)}} satisfies the constraint 

33. Commerce automata (CA) 

Negotiations upon variable values (e.g^ $priee) and 
business rules enforcement can be expressed by intentions. 
Such intentions are built by assigning commerce automata 
10 atomic variables, class variables and list variables that 
appear in intention trees. For the sake of simplicity, in this 
article, we do not consider automata tor list variables. They 
ore an extension of the automata for class variables. Fur- 
thermore, we consider business roles and negotiations In- 
volving two parries. However; it is possible to define ncgo^ 
tiation protocols involving more than two parties 

Variable*. Consider a CA A which is assigned to a van* 
able x of type t in an intention tree* If x is an atomic vari- 
able, executing A leads to the assignment of an atomic value 
of type t to In this case, the set of A's output variables is 
{(e). If » is a class variable, A specifies tm output Instance 
O of type f , where t f is a descendant oft In an ontology. 
Let 29* , . . be the atomic variables mat appear in O. 
Executing A assign* atomic values to soma of the variables 
among and assigns the resulting instanee to x. 
In this case, the set cfA's output variables is {xi 
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To build the assignment to the output variable*, A uses 
a set of internal variables which can be atomic variables or 
relation variables, variables that can be assigned entire 
relations. 

An automaton is provided with sm initial assignment to 
its variables (determined by unification, see the example in 
Section 4) and the assignment may be modified during its 
execution. The atomic variables are typed and the relation 
variables have an associated arity. 

Parties and messages. The execution of a C A is defined 
relative to two parties thai exchange messages. The roles of 
the parties during the execution are asymmetric. The active 
pony sends inquiry messages to the passive party* and the 
latter replies with answer messages. 

. Hie possible inquiry messages and the corresponding an* 
swer messages are; 

• 8&s\A $t. The active party requests an assignment for 
the variable $t The passive party replies withx, a value 

.• to assign to St.. 

♦ Confirm $ t=v. The active party requests a coafinna- 
tion regarding the assignment of value v to $l The pas- 

2 sive party replies with either Y as or Wo. 
- ♦ Choose n from H. The active party requests the pas- 
**t sive party to choose « tuples from relation R. The passive 
**i party replies with a relation containing » tuples from R. 
H ♦ Change column c in R. The active party requests 
SJ the passive party to modify column c in relation IL The 

passive party replies with the modified relation. 
U1 The relational store. During its execution* a CA can 

^ query the relations in its relational store which contains 
B (1) the relations in the active party's party information and 
grj (2) relations for relation variables. Furthermore, a CA can 
hj access me labels of vertices of intention trees. For exara- 
[I pie, the value of the Number leaf in the intention tree in 
*Z Figure 8 is given by Purchase. Parties .Custoiaer- 
^ . Address ♦ ISumber. 

« States, A CA has a set of states 5. One state is distin- 

guished as the starting state and there exists a non-empty 
subset Sj C S of final suites. Each state is labeled with an 
assignment program, t.c., a sequence of assignment state* 
meats. Given an assignment to the automaton variables, 
say a, the execution of an assignment program P modi- 
fies er by executing the assignment statements, one after the 
other. The assignment statements and their semantics are 
presented via the example in Table 1. 

the CA transition function* say 6, is applied to a 
state and a constraint and yields a state. For example* 
>srround ($x>) = means that if the CA is in state 
*i and the variable $x is ground (in the state of the current 
assignment) then the CA should move to state m % . 
Definition 3.1 (Commerce Automaton) A commerce au- 
tomaton, say A. is u tuple A = {S,h,S/,O t V 9 P, fj>,$) 
where: 




» S is a set of states. 

• b£ S is the starting state. 

• Sf C S is the set affinal states* 

• 0 is the output instance. 

+ V is the set of the automaton variables. 

• Pis a set of assignment programs and f ? is a function 
that maps states in S TO programs in P. 

• bis the (partial) transition function S : $ x SC —>S. 
where SC is the set of all SIMPLE-C constraints. O 

As part of a CA execution, messages are sent and an- 
swers are received. Formally, we model tha sequence of 
received messages via a stack of messages. Given an initial 
assignment er and a stack of answer messages I\ the execu- 
tion of the automaton is defined as follows. The execution 
begins ai the Starting sasne with Cht initial assignment- When 
the au t omaion en ten a state s a I modifies c by execnti ng the 
program / F (s). If f p (n) involves message exchanges, the 
answer to each inquiry message is popped from I\ We as- 
some mat if T is empty or the answer message in r does 
not correspond to the inquiry message, then the execution 
stops. The constraints On the transitions from s are checked. 
If none is TRUE, or more than one is TRUE, then the ex- 
ecution stops. If exactly one is true, the automaton moves 
to the new state. If no transition exits from s, the execution 
stops, in a. If the execution stops in a final state, then the 
execution is successful* and otherwise it fails. 

Consider the CA AMce in Figure 6(a) which is assigned 
to the atomic variable $price in the used car dealer's in- 
tention (Figure 9). The company uses this automaton in 
order to assign a value to ftarice. The starting state is 
1. First, the value of the variable $pricl (computed else- 
where as described in section 4) i$ assigned to Sprice 
and, using the Answer construct, the company asks the 
customer fox price confirmation. The customer's answer is 
assigned to the variable $ conf. If it is Yes. the automaton's 
execution is successful (state 2), otherwise it fails. It Jaife in 
state 1 (if the answer is neither Yes nor No) or in state 3 (if 
the answer is No). 

Consider the CA in Figure 6(b) (An order condition in- 
volving a variable which is not ground evaluates to FALSE). 
This automaton is assigned to a class variable, say ie y and, 
therefore, it defines an output instance (shown in Fig- 
ure 6(c)) that should be assigned to a?, in case the execution 
of the automaton succeeds. The automaton is provided with 
an initial assignment of its variables. If the initial assign- 
ment is the automaton enters state 2 and stops. 
Since 2 is not a final state, the execution tails. If the ini- 
tial assignment is {$fe)-+l, $&-»!} the two constraints are 
satisfied, therefore the automaton cannot move to the next 
state, and, therefore, stops (and fails) in state 1 . If the Initial 
assignment is { $ o-*l '} the automaton enters state 3 and the 
execution is successful: 2 and 5 are assigned to fa and $b, 
respectively, in the outran instance. 
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Table 1. An assignment program 



D 

rprice=Sp ri ci* 
ccca£«taa*art*i!< 




JBi 



Ground (5£>> 



:«*Yes« 



40 0 



(b)A«tottHOsB 



n a 

<c) Thi oonxn in- 
stance (of class 1) 
to bo defined by Au- 
tomaton B 



(a) Automaton Aftioc 

Figure 6. Commerce automata - The final states have double frames 



m 
o 
m- 

m 

M- 
M 

m 

s 

o 
m 
w 

*D 



We now formally define an intention and a party data 
structure. An inttntion is a tuple (T, j?, 5, C) where 2* is an 
intention tree, S is & set of CAs, f is a partial function from 
the atomic variables and the class variables that appear in T 
to 5. and £7 is a set of constraints. A party data structure is 
a tuple (51,1) where SI is the party information and 1 is a 
set of intentions indicating the £ Contracts die party is ready 
co enter. 

4. Unifying two intentions 
4.1. Basic unification 

The unification algorithm is an extension of the unifies 
lion algorithm for terms in logic (for example, see [13]). 
The algorithm is extended to handle operator vertices and 
CAs and is presented through the following example (the 
algorithm is formally described in the Appendix). The cus- 
tomer (whose intention tree is shown in Figure 8) has one 
constraint, i.e., that the cost is less than $300 <$pxice < 
300). The used ear dealer (whose intention tree is shown 
in Figure 9) has two OAs. The Acar CA. which is associ- 
ated with the variable &0&r in the intention tree, describes 
how cars are sold (Figure 7 contains a pan of the automaton 
definition)* The second CA, APrice (shown in Figure 6(a)), 
is associated with the variable frprica. PurchaseOnline's 
site ^formation consists of one relation Rcar(Modei. ID. 
Classv Price). 

The unification starts at the roots of the two inten- 
tion trees. In the Parties subtree, the Customer and 
trsedVehiclePealer- edges ere unified. Correspond- 
ing suborees are assigned to the variable & customer and 
acompstny. respectively. At the Vehicles subtree, the 
algorithm reaches an OR vertex In the customer's intention 
tree. In torn, each subtree under (ho OR vertex is unified 
with the Veiiicle subtree in the company's intention tree. 
The unification of the left branch obviously fails (since, h 
is impossible to unify a list of two motorcycles with a list 
that contains one car). At the right branch under the OR 
vertex of the customer's intention tree, the vertex labeled 
C*a? is unified with die vertex labeled S-Cnx in the com- 
pany's intention tree. Since the variable &Car is assigned 
to the Acar CA (shown in Figure 7(b)), the customer's sub- 
tree rooted in Car is unified with the output instance of die 
A car CA (shown in Figure 7(a)). This unification provides 
the inhkd assignment for die CA variables, ie,, Economy is 
assigned to $olaas. 

The Acar CA i* executed as follows. Since she variable 
. $ class is ground, the automaton moves to state 1. The 
automaton assigns to the relation variable A all the cars that 
correspond to the customer's Class specification (Economy) 
Then, Che automaton asks the customer to choose a model, 
This choice may be done in several ways; human interven- 
tion may be requested, or an automatic tool may be used. 



Such an automatic "expert" tool may, simply, choose an or* 
• bitrary car or employ more complex "user defined*" strate- 
gics. It can also try every choice, one after the other* and use 
backtracking if some choice leads to the failure of the au- 
tomaton execution. After receiving the model name, the an* 
tomaton selects the car, say (Cavalier, 322, Economy, 230), 
from the database (state 2). 

Following this assignment, the current constraint set 
(i$pr±cl 280, $price < 300}) is verified as sarisfi- 
able and the unification algorithm resumes. 

The unification proceeds to the Amount edge and the 
APrice CA (shown in Figure 6(a)) is executed. After 
confirmation, the new set of constraints {$pricl = 230, 
$price«230, $price < 300} is checked and the unirl- 
catioa proceeds to treat the Payment subtree. The generated 
ECon tract is depicted in Figure 10. 

4JL A Best Effort Unification Algorithm 

Here we address situations in which the unification al- 
gorithm Mis. We propose an approximate unification al- 
gorithm The basic underlying idea is that of upgrading 
parts of intention trees. As an example, suppose that an in* 
tention tree specifies the constant red in a node. Suppose 
further that Ibis is m fact a preference rather than an ulti- 
mate requirement One option is to use OR nodes and give 
additional color options (observe, that by the way the unifi- 
cation algorithm operates, priorities of colors are naturally 
assigned in left to right order). But, it's tedious to specify 
many colors, in addition the party may even allow any color 
as a last resort The solution we propose is to prioritize the 
(some of) the nodes and edges of the intention ctee. Apri- 
ority is a natural number, the higher the number, the more 
important is the constraint represented by the node. Simi- 
larly, constraints in the set of constraints associated with the 
intention may also be prioritized. 

If pririries are assigned to edges connected to the alter- 
natives of an OR node, AND node, or to list elements, men 
the highest priority alternatives within such OR* AND or 
list node are tried first (think of the Others as temporarily 
elhninnted), 5o» these priorities indicate an order for the 
unification algorithm. (This is not coded in the algorithm 
presented La the Appendix.) 

Priorities In nodes and edges can be used as follows. 
Suppose unification fails, one can take a low priority node 
and replace it with a Tees constraining*' one. This can be 
done by "upgrading** the node. An node upgrade can be 
any sequence of actions applied to nodes in the intention 
which result in a legal tree. Some actions apply to edges 
and make them less constraining. An action is defined as 
one of: 

J. Consider a node labeled with a variable of class e. the 
variable is modified to be of class csup* which is a 
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Supercnlss of class e„ The inodifjcation appli&a-to all 
occurrences of the variable. 

2. Consider a node kbd^d with a variable X. The node is 
labeled with ft variable V. If variable Y wears else- 
where in the intention, the node must be labeled with 

• the same class as in other occurrences. Variable Y may 
also be a ki frcsh new variable". 

3. Consider a node which is rite root of a subtree and la- 
beled by a (bound) variable. Make the variable un- 
bound by erasing the subtree, except for the node thai 
is now labeled with the unbound variable. The modifi- 
cation applies to all occurrences of the variable. 

4. Consider a list noda connected via edges to the list el- 
ements. Hirninate a list element, 

5. Consider a node labeled with a variable *X which is 
associated with automata (one or more). Change the 
set of associated axttomata, in particular* ^^association*- * 
wish automata altogether is a possibilkyr: 

6. Consider an edge e withlabel lab. Change lab to an- 
other label that appears in one of the'ist&n'dons or efcnv 
inate the label altogether.^ 

7. Consider node in the tree, connected via an edgtif *«to ■ 
its parent, which is the root of a subtree 2V Eirninate 
edge « and the subtree T altogether ToisMs a^drastic- 
measure that may be neede M? for exanwlermultipJox * 
versions of classes exist due to out of date or erroneous 
software. It is also possible that portions of trees are 
stored in various media or locations that may be inao- 
ceasible, temporarily or permanently. 

So. upgrading provides further options to the unification al- 
gorithm to explore. It may result in solutions that only "ap- 
proximate" true unification of the pre-up graded intentions. 
Thus, thib gives meaning to '"unify as much as possible". 

There are some technical issues to consider. One is that 
the upgrading of the least "important" node may not suf- 
fice to produce a unified intention. Further upgrades may 
be remiired. The issue is in* what order to perform mem. 
Suppose that 4 nodes: A3,C and ID are labeled with de- 
creasing priorities* say 4,3.2 and 1, respectively. An order 



that seems most reasonable is as follows (other orders are 
also possible): 

1. upgrade O; 

2. if above fails upgrade C; 

3. if above fails, upgrade C and T>; 

4. if above fails, upgrade B; 

5. if above fails, upgrade B and D; 

6. if above fails, upgrade B and D and C; 

7. If above mils, upgrade A; 

8. if above fails, upgrade A and D; 

9. if above fails, upgrade A and D and C; 

10. if above tails, upgrade A and P and C and B; 

We note that one may demand an aggregate condition in 
defining the 'fbest approximation", e.g.. as a function of pri- 
orities as well as the number of upgrades. Observe thai if 
a prioritized node u is the parent of another node v, once v 
is labeled with an unbound variable there is no need to try 
upgrades to node w. the node is no longer in the tree. 

Another Issue is that we are given two intentions, in what 
order should we apply the upgrades to these two intention*'? 
A reasonable way la to alternate between the two intentional 
One way to implement this is to map the priorities of the 
first intention to odd numbers and those of the second to 
even numbers, and than apply |h*m in priority order as de- 
scribed above. Other prioritizing schemes ate also possible. 

Constraints may be relaxed In a similar way. Here we 
may have more degrees of relaxation. For example, a < b 
may be relaxed to e < fc. Relaxation may also eliminate 
a constraint altogether. Here again, the priority of the con- 
straint indicates its importance and order of relaxation or 
elimination. 




5. The EContracts execution modules 

The execution modules are the unifier, which executes 
the unification algorithm, the constraint sohrer y which en- 
sures the satisfiability of constraint sets generated during 
unification and the automata execution engine* which is 
responsible for the execution of commerce automata. All 
these modules are organized and activated when needed by 
the negotiation control program (NCP) (see Figure 1). 

♦ The Constraints Solver When needed, the NCP deliv- 
ers a set of constraints to the constraints solver. The 
constraints solver returns to the NCP an answer which 
may be either Unsatief labia, in., it Is impossi- 
ble to find an assignment to the variables that appear 
in the constraints such that the constraints are satisfied, 
or Satisf iable, there exists a satisfying assign- 
ment If die constraints solver returns Satisf labia, it 
may return a modified (and simplified) constraints set 

# The Automafci Execution JSngine (ABE) When needed, 
the NCP requests the AEE to execute an automaton. The 
NCP and the AEE may not belong to the same party. 
Por example, when una tying the intentions of Party A 
and Party B, Party ATs NCP may request from Parry B's 
NCP to forward a request of an automaton execution to 
Party B'S AEE. When the execution ends, the AfiB re- 
turns either SUCCESS, i-e., the CA reached a final state, 
or FiaLURE,^ the CA did not reach a final state. If the 
AEE returns SUCCESS, the NCP may modify the ECon- 
tract by utilizing the CA's output 

• The Unifier executes the unification algorithm cm two in- 
tentions submitted by ihe NCP. If it suceeeds, the unifier 
module returns the E Contracts. Ihe unifier module may 
occasionally request the NCP to pass a set of constraints 
to the constraint solver or to pass a CA to the AEE for 
execution (the AEE may be the AEE of either Party A or 
Party B). 

• The Negotiation Control Program is the main execu- 
tion module. The NCP manages the negotiation process 
between the parties and coordinates the activation of the 
other execution modules. 

6. Related work 

We do not intend to give an exhaustive overview of 
research in EC References regarding authentication and 
payment can be found in (18]. References to a game* 
theoretic approach lo automated negotiation can be found 
in [161. Some applications of agents technology are related 
to EC (14), e.g., information- brokers f7J and Kasbah [61. 
Agent systems are mostly task oriented and do not define 
a general framework for negotiation. Usually, the agents' 
business model Is encoded in its program and therefore, 
practicnJIy, cannot be analysed. Tb& W3C EC interest group 




(wwu?. w3 .org) is working towards standards in the do- 
mains of micropayment, security, and public policy. The 
combination of XML and EDI is discussed in [21]. 

The Eco system [17] implements an architecture for In- 
ternet commerce. Eco has some limitations in comparison 
to EContracts, Messages and knowledge bases are writ- 
ten in high level analyzable languages (KQML (12) and 
KIF 19]). However, agent behavior is described using com- 
mon programming languages which are difficult to analyse. 

Important concepts of the EContracts framework are 
class, class hierarchy and ontology. Our framework is simi- 
lar to the approaches of [20, 15]. Commerce automata have 
roots in the works of [1] and (4). 

The execution modules benefit from extensive research 
m constraint programming [10, 19] and logic program- 
ming [13]. In particular* unification of class structures is 
described in [3]. 

Relational databases are also used as a foundation for 
EC hi [8], an active, database model is used to capture 
the semantics of the constantly changing EC environment 
In [21, business models are formalized using relational 
transducers. In [51, ideas similar to ours are presented; 
however, a complete framework is not described. A pre- 
liminary version of this work has been presented in [1 lj. 

7. Conclusions and future work 

The EContracts framework enables (semi-)autoniated 
EC The framework defines standard data structures and 
execution modules that comprise an autonomous party. 

We are extending our model to support open EContracts, 
Le., contracts in which a deal Is not totally specified when 
the EContracts is signed. In such an BContract, it is possible 
to encode, for example, that the model of the purchased car 
is open and will be fixed by the customer while the final 
price is between $250 and $300 and will be fixed ultirnataly 
by the used car dealer; 

We plan to develop a practical marketplace based on 
EContracts. We also plan to work on theoretical problems 
such as deal feasibility, analysis of negotiation strategies 
and optimisation of negotiation behaviors. 
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A* The unification algorithm 

Tbe input of the nnifioatten algorithm is two intention 
trees J t and 1». C ia the set of global constraint* defined 
on Ji and /a. We assume that I\ and J a do not contain 
OR vertices (we can remove all the OK vertices from an 
intention tree as described informally in Figure ll\ 



The algorithm is described in a Prolog-iike language. We 
- • assume the existence of the following predicates: 
instancc(T t S) Generates an isomorphic copy S of T with 
a disjoint $a of variables (including association 10 au- 
tomata). 

vqt{V) Satisfied if V is an unbound variable. 
nonvar(V) Satisfied if V is not an unbound variable. 
aiomic(V) Satisfied if V is an atomic variable. 
classiy) Satisfied if V ia a class variable. 
intlV^floaiiV), strino(V} Satisfied if V is ground and is 

as integer (float, string, resp.). 
rnodc(V, Structure, Type.) Satisfied if variable V has the 

structure Structure (Structure can be: atomic, class 

or list) and type Type {Type can be: int. float, string or a 

class name), 

hasseri[Edb) Backtractabie assertion of the fact Edb. 

brelrad (Edh) Backtractable retract of the fact Edh. 

cl/iAsfiesclCi , Ca) Class O x is a descendant of class C± in a 
class hierarchy of an ontology. 

axctor^aton(V ) A i O, ModeStmi) Satisfied if automate* A 
is assigned to V, its output instance is O and &* mode 
statement is ModeSirnt. 

mn(A, O) Execute automaton A on instance O. 

checkCo*$1rai*U(T t C) Satisfied if the variables in T sat- 
isfy the constraints set C. 

permatedXu. ..*.]. . .%]) Satisfied rf fy u .:.Y n ) 
is a permutation of {X\ , . . . X n ) . Backtracking goneraies 
the ^next^ permutation. 
Too Unification Algorithm follows: 

U nifi c at ion Algorithm 
/♦Main*/ 

/* We assume that a tact (clause) is asserted prior to 
running the unification, for each of the variables in 
tbe input intentions h and J 3 , in the following way: 
o*aerl{rnode(voriaiie name, tfrue*stre,ff(pe)).*/ 

/* Run Unification; tbe result is h . */ 
rnainjunificxiltcm{h , ft) unif^(h%h)% 

eheekCcngirainUih , C), tmrfte(Ji). 

/* Use symmetry. */ 
unify(J i9 J%) +~ unifyl{l x , JTi), 
wiiMh , I») - uni/2/l(J a , I x ). 

y* Onixyinga Classes. */ 
«ns/yl(Ti,T 2 ) nonear(71) t awtfarfrj), 

r x ^ ONi {£t - ft C*), 

/* C'N,- is class name, Ej is edge label to subtree ft. */ 

3i - CJYj ( JFi - £>j , - . . , Ft - £>* ) , 
. classiCtfx), c1a**[CN<t), 

Wifvid , £>i) 9 ...,unify{C»t X>*). 
/* Unifying 2 Uett.*y 




CD' 



t X> 1 [SJ 
(a) Ttec T - T a , T a , Jt, C. P. JET a*4 
the Rlfcfctti rimofttri by ...do act COaEtifi 

ORvrtucc*. 
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Figure 11. Removing OR vertices: an Informal explanation 



fwrmtde([Ci, . . d], [Xu . . . , X*]) T 

imVlK^i , Ui), .... uni/iK** , At). 

/* Unifying & List and a superset constraint*/ 

T x = . . . , C*), T 3 ~ OO^ , . - . , An)> 
m < *,/»2y« elements mast include Ta's. */ 
jper/mrtaftCi, . . . , C k ] t [X u . . . >X k ]) % 
vnifyiDx , Jti), .... u*ify{D m , 
/* Boih 3\ and T% are rooted at a NOT vertex. */ 
/* There is no need to unify Ti and 
um/yl(2i ,7b) — n*nvar(Ti) 9 rw>m?a*(jft), • 
T t & NOT(STi), 

2. 

is rooted at a NOT vertex. */ 
wm*/yl(Ti,T a ) «- no7iwor(Ti), 

r x irorcsaiE). 

^(uni/i/fSTi.Ti). 
/*2\ u rooted at an AND vertex */ 
uniJpl(TuT 7 ) nonvar(T!) # 

*i*s/y(S7\ , 7i), vnify($Ti ,7a). 

/* We only list rules for integer constants and variables. 
Similar rules apply for the float and string atomic data types, 
*J 

f* 2 constants*/ 

f* Assigning a constant to a variable. •/ 
unifpl(Tx,T 9 ) «~ variTt), 

mode(Ti t atomic, int), int(7%)> 
hretrad(mode(T\i atomic, int)), 
T X = T % . 

/* 2 atomic variables, *7 
imt/j/UTwTa) ^ wCR). var{T 7 ), 
mod&(T\ , atomic, int). 



moduli, afomic, *>rt), 
^r^rnci(r«ode(^, niomic.itU)), 

/* Assigning a class instance io a class variable. */ 

mo<U(Ti t eta**,X), 

- ONiEi - C lt . . . , E k - C*), c!a*i(CN\ 
cl**9D**c(CN t X) t I* CN is subclass of X. */ 
fcreiroct^rnoo'e^ , eJua&, X)), 

/* 2 class variables, */ 

r/*ock(7i t c/c**,X), 
m*de(r 2 ye*oas,y), 

hretraci(rnode(Tu das*, X)), 

/* Assigning a'list to a list variable. */ 
imi/yj (05,2*2) *- vurCTi^nonvar^a), 
modest, iirt, X> 
T 35 =L((?i <?*). 

/* Need to check: whether the list variable and the list's 
items have compatible types */ 
bas$trt(modt(Ax , X)), • . , , 

loa«art(m^de(A^, -»^))« 
unify(At k ft), . . . , um/j/(/4 A , 
^rcet(mode(2\ , lixt t X)) 

A list variable and a superset constraint. */ 

/* No unification is done, the constraint is noted */ 
baxscrilcenstraintiC®, T Xl 
/♦ 2 list variables. */ 



clu»sDcsc(Y,X), 
6ret7act(mode(Ti i clo3s,X)) t 
2» * 3d* 

/* Unifying an automaton variable, V 

avi crmalon(T\ , A, O, ModtStmt), ba$sert(M 'odcStttt), 

J* Need a copy of Xi because automaton execution w 
possibly at a remote site — different environment.*/ 

intrtanc*(Tz, I), vnify(0 9 J), /• Prepare automaton 
Inputs"*/ 

nm(w4> O), unify{O t T{) , u»t/y(0, T 3 ). 

/* Special case: unification of 2 simerset entrants. */ 
unifyl(T t — ftw*r(7i), nonvar(T 2 ), 

Ti*€&(Ci C h ). 

/* No unification is done, constraints are noted. */ 
husteri {constraint (CO , 3\ , T*)) 

Note thai if unbound variables appear in a subtree rooted 
at a NOT vertex, it is possible for the unification algorithm 
to tail while reaching an agreement w» in tact possible. 
This problem *ri&*4 bac*ufie thft unification order is fixed by 

prolog and does not take into account that unification with 
subtrees rooted at NOT vertices may be done after all the 
relevant variable bindings are deterrnined. In such a case, 
it is possible to modify die intention trees so that the Stan* 
dard order of unification leads to a correct resale. However, 
details are beyond the scope of mis paper. 



Glossary 



Computational device: a device used to perform computations, it encompasses 
hardware (e.g. mechanical, electronic, chemical or biological) and software 
(programs, executables, byte-codes, systems, servers and the like) as well as a 
computer system or part of a computer system, a database, a server, or a 
communication system. 

EC Party; A legal entity that may be involved in a deal. In particular, it can designate 
individuals, corporations, countries, stale and local authorities, organizations and 
associations. 

Intention: A specification of constraints to be satisfied by a deal. By a specific 
example said constraints designate the objectives of the deal (e.g. t buy, rent), parties 
and objects involved in the deal,. and limitations that are applied to these entities. 
Component: A component is an entity that is a building block for intentions. 
Atomic component: A component describing a simple entity such as a bit, a number 
or a string. 

Compound component: A component that is built of other components. 
Constraint component: A component describing constraints on other components, 
e.g, that one atomic component is larger than another. 

Basic component: A component whose structure is known to a user community and 
is agreed upon as representing a real life concept. Basic components are named. 
Variable component: A component that is represented by a variable. 
Computable variable component: A variable component that is associated with one 
or more computational devices. Such a device transforms thai variable into a 
component. This component usually4ncludes furtherielaboration^on*the*deakv 
Fitting: A process of taking^one or more intentions and reconciling them*into * 
intentions that together satisfy <as much as possible the constraints prescribed by the 
original set of intentions. 

Contract: A set of intentions that are agreed upon by the issuing parties. In particular, 

if that-set consisting of one intention it's called^a simple contract. If it includes no 

variable components it is called a groundtcon tract 

Atomic yalue: a concrete»representation<of an atomic component? 

Atomic type: A set of atomic values. 

Class: a prototype of a compound component, for example 6 cla*s in Java or 0+* f a 
compound term in logic programming (Prolog), & list structure in LISP, etc. The 
specification of a class can involve atomic types, values and classes. A class usually 
has a name. 

Class value: a particular instance of a class prototype. 
Basic class: A class that constitutes a basic component 
Variable: An entity witha name, a type (atomic, class, atomic collection, class 
collection where a collection is, e.g., list, set, subset, superset, ono-of, array) and value 
(either atomic value, class value, undefined (called null), or a collection of values.) 
Computable variable: A variable ihat is specified to be a computable component. 
Abstract class: A class that has a name bui no class instances. It used to abstract 
classes that appear a class hierarchy (see below). 

Sub-class relationship: A statement that a class, say A, is more general than a class, 
say B. Classes A and B need not have similar prototypes- Classes may be abstract. 
Class hierarchy: A collection of sub-class relationships. It is sometimes<<rcquired that 
this relationship' be transitively fron*eyclic; i.e., that*a classes notnts own*subelas$. 



Ontology: A collection of class hierarchies. It is sometimes required that no class 
name appears in more than one hierarchy of the ontology. 

Item ontology; A particular ontology that usually contains names of basic classes that 
correspond to objects or concepts, for example car, bank account, John, Pepsi Co.. 
General ontology: A particular ontology that usually contains names of basic classes 
that correspond to transactions, for example buy, rent, lease, transport, invest, destroy, 
build 

Party information: A set of information items an EC party maintains. This set 
usually contains its identity, a collection of intentions, and other data relevant to its 
operation. The party information may change dynamically over time. Parts of it may 
be published for outsiders to access/view and parts of it may be restricted in terms of 
who and when can access/view them. 

Operator class: A class that indicates constraints on values. Examples are OR, AND, 
NOT and ONE-OF. 

Intention trees; An intention built by the following process. One starts with an 
instance of a general class and then may extend it via zero or more extension steps. 
Extension step: An extension step is performed by: replacing a null atomic variable 
by an atomic value, or by replacing a null class variable with a new fresh copy of a 
class prototype, or by replacing a null collection variable by a collection of values, or 
by introducing an operator class instance and modifying the intention in accordance to 
rules of introduction of operator classes. 

Constraint; A constraint component specifying limitations on values variables may 
be associated with, on relationships concerning variables and values, and on 
aggregates of values. 

Message: Communication of information between one or more computational 
devices. 

Reply: A message that is sent as a response to another message or messages. 
Relation; A form of representing a collection of information items, each item is 
composed of fields and values for these fields. 

Commerce automaton: A computational device that is specified using states, 
transitions among states, predicates on transitions, actions to be performed in a state, 
the forms of input, the forms of output. In particular, actions may be the sending or 
receiving of messages and creationyd^truction/access/modification of values of 
variables including variables associated with relations and other relations (e.g., those 
associated with party information). A computed variable component is associated 
with one or more commerce automata. 

Unification of intention trees: The fitting of intention trees. The process involves 
matching of similar components, the assignment of values to variables, the execution 
and/or analysis of commerce automata, exchange of messages. The result is one or 
more intention trees that satisfy as much as possible the constraints expressed by the 
original intention trees. If the parties, that present the original intention trees, agree 
upon the result, an electronic contract (EContract) is said to result The EContract is 
ground if all variables are assigned non-null values The EContract variables may be 
associated whh party or parties that are to detennine their actual values at the point of 
execution of deal(s). . The EContract is single if it consists of a single intention. 

Party machine (P'M): A computational entity employed by an EC party which 
controls the process of fitting of intentions. The PM may communicate 
with other computational devices, and in particular other PMs, in 
attaining its mission. The major components of a PM are: 



1 . A Negotiation Control Program (NCP) is an overall coordinator. 

2. A Constraints Solver is used to check, simplify, solve and evaluate 
sets of constraints. 

3. An Automata Execution Engine (AEE) executes commerce automata. 

4. The Unifier supervises the unification process. 



CLAIMS : 

1. An automatic electronic commerce system, comprising: 

(a) plurality of parties, each including at least 
one intention that specifies deal constraints 
that said party is ready to engage; each 
intention contains at least one component and 
at least one party of said plurality contains 
at least one variable component associated 
with at least one computational device, which 
when activated at a given state transforms 
said variable component into a component. 

(b) Party machine (PM) that includes at least a 
fitting module capable of fitting at least 
two intentions, so as to produce a deal that 

□ meets as much as possible the deal 

\=k constraints of said at least two intentions; 

Iff said fitting includes matching components in 

y= one intention from among said at least two 

vj intentions with counterpart components in 

another intention from among said at least 

{H two intentions; for any variable component 

J 2 from among the components stipulated in said 

p (a) , activating the computational device 

U associated with said variable component in 

jVj order to transform it to a component as part 



jT of applying said fitting 



*0 



device 



2. For use in the system of Claim 1, a computational 
e. 

3. For use in the system of Claim 1, a fitting module. 



4. For use with the system of Claim 1, a matching 
component . 

5. An automatic electronic commerce method, comprising the 
steps of: 

(a) providing a plurality of parties, each 
including at least one intention that 
specifies deal constraints that said party is 
ready to engage; each intention contains at 
least one component and at least one party of 
said plurality contains at least one variable 
component associated with at least one 
computational device, which when activated at 
a given state transforms said variable 
component into a component - 



(b) 



fitting at least two intentions, so as to 
produce a deal that meets jas much as possible 




the deal constraints of said at least two 
intentions; said fitting includes matching 
components in one intention from among said 
at least two intentions with counterpart 
components in another intention from among 
said at least two intentions; for any 
variable component from among the components 
stipulated in said (a) , activating the 
computational device associated with said 
variable component in order to transform it 
to a component as part of applying said 
fitting. 



6. Memory media containing at least one computer 
executable program capable of 

0* (a) identifying a plurality of parties, each 

P including at least one intention that 

M= specifies deal constraints that said party is 

iff ready to engage; each intention contains at 

M least one component and at least one party of 

N[ said plurality contains at least one variable 

\n component associated with at least one 

Ul computational device, which when activated at 

B a given state transforms said variable 

O component into a component. 



fitting; at least two intentions, so as ,to 
produce a deal that meets as much as possible 
the deal constraints of said at least two 
intentions; said fitting includes matching 
components in one* .intention from^among said 
at least two intentions with counterpart 
components in another intention *from -among 
said at least two intentions; for any 
variable component from among the components 
stipulated in said (a) , activating the 
computational device associated with said 
variable component in order to transform it 
to a component as part of applying said 
fitting. 



